home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1235.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  3.2 KB  |  59 lines
  1. Well, I knew everyone would disagree with me. Thank you for doing so politely.
  2.  
  3. I'd like to make it clear that I do *NOT* suggest line breaks and / or
  4. page breaks to annoy people, nor because I have a specific interest in
  5. poetry (though I do). Dave Raggett suggested a <poem> tag, and as I saw
  6. no smiley, I assume he was at least semi-serious. IMHO, the idea sucks.
  7. T V Raman made a similar comment about representing the high-level
  8. structure of a poems, but I would claim that that is not the business of HTML.
  9.  
  10. The general philsophy is to be "Keep HTML minimal". I agree, and concur
  11. with the idea of embedding e.g. GIF and TeX. You are right, Dave, that
  12. HTML must not be all things to all men. I would add "or anyone for that
  13. matter". So - let us maintain the high-level representations of our
  14. docs (e.g. poetry) in our authoring systems, and then PUBLISH them as
  15. HTML. Some poetry is published on e.g. audio tape, but the vast
  16. majority is published on paper and obeys the conventions of line
  17. breaks, verse breaks, page breaks etc, even though the author may
  18. COMPOSE it in very different terms that just don't come across when
  19. reading it. My feeling is that HTML should provide low-level PUBLISHING
  20. functions, but not aetherial concepts or <poem> tags.
  21.  
  22. My best suggestion is an argument to <pre> ; e.g. <pre monofont> and
  23. <pre normalfont>. Or maybe <pre style="em">, where the style argument
  24. can be any valid text style tag or "plain"? This allows me to separate
  25. the lines of my address (or poem) properly, introduces no extra tags,
  26. and <pre> with no argument can default to the normal meaning of
  27. "monospaced, to suit a listing or programming example".
  28.  
  29. OK, on to "page breaks". Or since, this kind of terminology seems to
  30. offend people, may I suggest "multibody files"? It occurs to me that a
  31. special "page break" tag is unneccesary. All we need is a well
  32. established method of handling multiple <body></body> pairs in one file.
  33.  
  34. * Browsers can search across a whole set of short bodies
  35. * Browsers don't have to try to whack the whole of an enormous file onto a text 
  36.   widget. XMosaic already has to break large files into "pages", so it seems 
  37.   like a good idea to make the "pages" more logical.
  38. * Most authors and (the tools they use) consider multiple chapters of one 
  39.   document to logically belong in one file.
  40. * Most readers don't read large documents from page one and progress to the end
  41.  
  42. An obvious example is a technical manual or a Usenet FAQ. All I want to
  43. see is the index and/or table of contents, then the chapter or section
  44. which answers my question. I don't want to wait for vast quantities of
  45. gunk to be mapped into a window ESPECIALLY if it contains inlined
  46. images (e.g. the Vatican library document index). Just show me the
  47. section which is relevent. OK, if I then want to browse down the index,
  48. fine, but let it be my choice.
  49.  
  50. It's possible that these things are solved better by Dave Raggett's
  51. html2 DTD, but I can't get to hplose.hpl.hp.com. Care to give us the IP
  52. address while your netbods set up the name, Dave?
  53.  
  54. Peter Lister                                    p.lister@cranfield.ac.uk
  55. Computer Centre,
  56. Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
  57. Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875
  58.  
  59.